Virtual private LAN services (VPLS) over MPLS provides LAN-like connectivity between geographically diverse customer locations. Draft standards for implementing VPLS over MPLS are presented in “Virtual Private LAN Services over MPLS”, IETF draft-lasserre-vkompella-ppvpn-vpls-04.txt, March 2003, and “Virtual Private LAN Service”, IETF draft-kompella-ppvpn-vpls-02.txt, May 2003, “Transport of Layer 2 Frames over MPLS”, IETF draft-martini-12circuit-trans-mpls-09.txt, April 2002, and “Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS networks”, IETF draft-martini-12circuit-encap-mpls-04.txt, November 2001, all of which are incorporated by reference herein.
The basic operation of VPLS is described with reference to FIG. 1 and involves establishing virtual circuit (VC) label switching paths (LSPs) and tunnel LSPs (also referred to as “pseudo-wires”). FIG. 1 depicts an MPLS domain 102, three service provider edge devices (PEs) 104, geographically diverse customer edge devices (CEs) 106, and customer LANs 108 for two different customers, customer A and customer B. FIG. 1 also depicts corresponding tunnel LSPs 110 between the PEs and examples of VC LSPs (e.g., VCA LSP and VCB LSP) that are carried within the tunnel LSPs. In operation, an Ethernet frame from a customer location is either switched or routed by a CE to one of the PEs (also known as MPLS label edge router (LERs)). The respective PE classifies the frame based on either the incoming port or the virtual local area network (VLAN) identifier (ID) of an IEEE 802.1q tagged frame. The frame is then mapped to a user-defined Forwarding Equivalence Class (FEC), which specifies how the frame gets forwarded. The FEC lookup yields the outgoing port of the frame and the tunnel and VC labels that are used to encapsulate the frame. FIG. 2 depicts an example of a frame encapsulation format for implementing VPLS. A complete description of the frame format is described in the above-referenced IETF document entitled “Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS networks.” The frame format includes the original Ethernet frame 220, an MPLS label stack 222, and an outer Ethernet header 224. The outer Ethernet header identifies the next hop of the frame during transport through the MPLS domain. The label at the top of the MPLS label stack is the tunnel label, which is used to transport the frame across the provider's MPLS domain via the tunnel LSPs. The label at the bottom of the MPLS label stack is the VC label, which is used by egress PEs to determine how to process a frame that is exiting the MPLS domain. The original Ethernet frame is the customer frame that is transported between the geographically diverse customer locations.
During transport through the MPLS domain 102, backbone label switch routers (LSRs) (not shown) in the MPLS domain only look at a frame's tunnel label to switch the frame through the MPLS domain. The tunnel label at the top of the MPLS label stack is removed at the penultimate hop (i.e., the hop prior to the egress PE) and the frame is passed to the egress PE with only the VC label. The egress PE uses the VC label to determine how to process the frame. The frame is then forwarded to the outgoing port that is identified via the VC label.
The VPLS architecture described above with reference to FIG. 1 can be modified to improve scalability. A standardized architecture for improved scalability is referred to in the above-described documents as Hierarchical VPLS or “HVPLS.” FIG. 3 depicts an example of an HVPLS-based network architecture, which includes Layer 2 devices, referred to as multi-tenant units (MTUS) 312, located between the PEs 304 and the CEs 306 to create hierarchies with a hub-and-spoke arrangement. Using the HVPLS architecture, a full mesh of tunnels 310 is maintained between the PEs within the MPLS domain while additional LSPs 314 are established between the PEs 304 and MTUs 312. The hierarchical architecture reduces signaling and frame replication overhead and as a result large scale VPLS services are easier to deploy.
To provide viable VPLS services, a service provider must be able to test the connectivity between nodes in its VPLS-based network. In particular, it is important to be able to test the paths that are traveled by actual customer traffic. Two categories of testing functionality that are common in network management involve testing end-to-end connectivity between two nodes (often referred to as a “ping” test) and learning the path that traffic travels to get from one node to another (often referred to as a “traceroute” or “tracepath” test). Well-known “ping” and “traceroute” functionality has been developed for Layer 3 networks (e.g., IP-based networks). Although the ping and traceroute functions work well in IP-based networks, these functions are not exactly transferable to Layer 2 networks such as VPLS-based networks. Solutions for providing Layer 2 ping functionality have been implemented and accepted however there is no widely accepted technique for providing the traceroute functionality. One proposed solution for providing traceroute functionality is described by Stokes et al. in an IETF draft document entitled “Testing Hierarchical Virtual Private LAN Services” (draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt), June 2003. This proposal for providing traceroute functionality in a VPLS-based network depends on retaining the value in the time-to-live (TTL) field of the MPLS tunnel label when the tunnel LSP is switched at a PE. Retaining the TTL value in the tunnel label through an LSP switch can be difficult to implement because it requires additional information to be switched from an ingress port to an egress port.
In view of this, what is needed is a technique for obtaining path information related to a VPLS-based network that is easy to implement and that reflects paths that are traveled by actual customer traffic.